Re: disclosure / definition of "patch"
Pat Myrto (rwing!pat@ole.cdac.com)
Fri, 2 Dec 94 9:28:29 PST
"In the previous message, James R. Ault said..."
>
>
> > Surely there is a third way: time-lapsed full disclosure. When a problem is
> > discovered, don't announce it until there's a patch, then announce
> > the problem and the patch together, without exploitation information.
>
> But there's one other problem here: Depending on the definition of
> "patch" and "exploitation information", this could be describing both
> CERT and 8lgm.
>
> Does a "patch" have to come from a vendor? or does a drop-in replacement
> from bugtraq qualify as a "patch"?
I've used that term myself, and with 20/20 hindsight, its a less than
optimum choice off word - 'patch' should really mean 'fix' or similar,
and is NOT necessarily vendor supplied. 'Patching' describes a lot of
possible operations.
> CERT doesn't announce it until there's a patch _from the VENDOR_, and
> there is no exploitation info to make the vendor hurry at all, so they dont.
They may not announce even then.
> CERT also probably considers the phrase "binmail uses tempfiles that
> are created unsafely" as exploit information, while most of us on
> bugtraq don't.
Yeh, They would say "A vulnerability exists".
> I was very grateful for the mail.local replacement that was posted to
> bugtraq, and I installed it, and I am convincing others to install it
> also.
Thats what full disclosure (whether full canned ready-to-run exploit scripts
or sufficient info one can test to see if something fixes the problem)
allows. W/o that information, such fixes as mail.local would not be
possible, because one who wishes to try that route would be unable
to verify whether there is a benefit or not.
> This often comes down to philosophy. Some sites prefer to install
> only vendor code and patches, some are willing to replace pieces, some
> run a completely free OS anyway. There is a wide difference between
> those who do/don't care about security, _and_ those who have or make
> time to deal with it.
>
> So, when you advocate a stepwise approach: make it clear that any
> _workaround_ whether it is a replacement program or a chmod command or a
> vendor patch would be an acceptable fix. "patch" needs to be more
> clearly defined. CERT waiting for the vendors is what makes them take
> so long.
I guess it needs to be made clear that 'patch' does NOT necessarly mean
a vendor fix - it could also range from a replacement to changing
something in a binary or whatever with adb (also called 'patching').
> I much prefer a workaround like mail.local from bugtraq, but it comes
> down to who you decide to trust...
I consider mail.local a *FIX*, rather than a mere workaround (the latter
suggests something like disabling a SUID bit, or removal of the service,
and is generally temporary in nature till something better is devised).
there is no loss using mail.local (who uses binmail as a reader or
user agent)?
> Jim Ault, CS Sysadmin, SUNY Albany, NY 12222 USA ault@cs.albany.edu <><
>
--
pat@rwing [If all fails, try: rwing!pat@eskimo.com] Pat Myrto - Seattle WA
"No one has the right to destroy another person's belief by demanding
empirical evidence." -- Ann Landers, nationally syndicated advice columnist
and Director at Handgun Control Inc.